IBIS Macromodel Task Group

Meeting date: 23 March 2010

Members (asterisk for those attending):
  Adge Hawes, IBM
* Ambrish Varma, Cadence Design Systems
  Anders Ekholm, Ericsson
* Arpad Muranyi, Mentor Graphics Corp.
  Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
  Brad Brim, Sigrity
  Brad Griffin, Cadence Design Systems
  Chris Herrick, Ansoft
  Chris McGrath, Synopsys
* Danil Kirsanov, Ansoft
  David Banas, Xilinx
  Deepak Ramaswany, Ansoft
  Donald Telian, consultant
  Doug White, Cisco Systems
* Eckhard Lenski, Nokia-Siemens Networks
  Eckhard Miersch, Sigrity
  Essaid Bensoudane, ST Microelectronics
* Fangyi Rao, Agilent
  Ganesh Narayanaswamy, ST Micro
  Gang Kang, Sigrity
  Hemant Shah, Cadence Design Systems
  Ian Dodd, consultant
  Jerry Chuang, Xilinx
  Joe Abler, IBM
* John Angulo, Mentor Graphics
  John Shields, Mentor Graphics
* Ken Willis, Sigrity
* Kumar Keshavan, Sigrity
  Lance Wang, Cadence Design Systems
  Luis Boluna, Cisco Systems
  Michael Mirmak, Intel Corp.
* Mike LaBonte, Cisco Systems
  Mike Steinberger, SiSoft
  Mustansir Fanaswalla, Xilinx
  Patrick O'Halloran, Tiburon Design Automation
  Paul Fernando, NCSU
  Pavani Jella, TI
  Radek Biernacki, Agilent (EESof)
* Randy Wolff, Micron Technology
  Ray Komow, Cadence Design Systems
  Richard Mellitz, Intel
  Richard Ward, Texas Instruments
  Samuel Mertens, Ansoft
  Sam Chitwood, Sigrity
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence Design Systems
  Sid Singh, Extreme Networks
  Stephen Scearce, Cisco Systems
  Steve Kaufer, Mentor Graphics
  Steve Pytel, Ansoft
  Syed Huq, Cisco Systems
  Syed Sadeghi, ST Micro
  Ted Mido, Synopsys
  Terry Jernberg, Cadence Design Systems
* Todd Westerhoff, SiSoft
  Vladimir Dmitriev-Zdorov, Mentor Graphics
  Vikas Gupta, Xilinx
  Vuk Borich, Agilent
* Walter Katz, SiSoft
  Wenyi Jin, LSI Logic
* Zhen Mu, Mentor Graphics

------------------------------------------------------------------------
Opens:

- Bob would like to speak about roles and responsibilities

--------------------------
Call for patent disclosure:

- No one declared a patent.

-------------
Review of ARs:

- Walter send split-up AMI BIRD documents to ATM reflector
  - Done

- Arpad: Write a clarification BIRD to discuss accuracy issues related to the 
  various AMI clock_tick algorithms in an IBIS-AMI DLL
  - TBD

- Arpad:  Write parameter passing syntax proposal (BIRD draft)
          for *-AMS models in IBIS that is consistent with the
          parameter passing syntax of the AMI models
          - TBD

- TBD:    Propose a parameter passing syntax for the SPICE
          - [External ...] also?
          - TBD

- Arpad:  Review the documentation (annotation) in the macro libraries.
          - Deferred until a demand arises or we have nothing else to do

-------------
New Discussion:

Bob clarified task group roles:
- Bob reports to Arpad in this group, but is speaking as IBIS chair now
- The task group is only to provide proposed specs to the Open Forum
- IBIS 5.0 is the official AMI spec
- IBISCHK is the official checker
- Nothing changes until the IBIS committee approves a new spec
- Deprecation is a serious concern, but everything remains until approved
  otherwise
- The biggest concerns are clarity and process
- Arpad: What are we doing incorrectly?
- Bob: We don't know what the goal is
- Arpad: We are responding to specific problems discovered in 5.0

AR: Bob and Arpad meet to discuss group goals

Ken Willis gave a feedback presentation from Sigrity:
- Presentation is posted on the ibis-atm website
- Slide 3:
  - Ken: Could be problems with Init_Returns_Filter
    - The existing API can already do time domain and statistical analyses
    - Could get different results from the same model
  - Arpad: This means different results from different tools?
  - Ken: Even from the same tool
- Slide 4:
  - Ken: Is the proposal to remove existing branches still on the table?
  - Walter: Yes
  - Ken: Would rather not drop them
- Slide 5:
  - Ken: Tx_Jitter and Rx_Clock_PDF should be kept
- Slide 7:
  - Ken: We found good uses for Table, would rather keep it
- Slide 8:
  - Ken: Is Array only for Tap?
    - We may not need it
    - The same goes for Step and Increment
- Slide 9:
  - Ken: We should be able to simply clarify without adding keywords
    - Fewer data types are better
- Slide 10:
  - Ken: Anything new should do something that can't be done today
    - There should be golden data to test against
  - Arpad: Agree that we should try to avoid mission creep
- Slide 3:
  - Walter: We should be able to give the option of Init_Returns_Filter
  - Ken: The model can write extra information as files
  - Walter: That can be considered
    - How would the EDA tool know the model can do that?
  - Kumar: The tool can figure it out
  - Todd: The purpose of a standard is to have a standard way to do it
    - We can't have different tools doing it different ways
  - Todd: It's useful to have a model that can do approximate LTI
    - It should not require 2 different models
  - Kumar: It's up to the EDA tool to do that
    - It would be better to have 2 different models

Questions followed the presentation:
- Slide 4:
  - Walter: Some reserved params really tell you how the model works
    - There are different kinds of jitter params
      - They are used by EDA tools to analyze results
      - A separate Jitter BIRD will put all of them together
      - Jitter may be handled by the EDA tool, not DLL
      - But some tools may work differently
      - It should be in the model
    - For example if Tx_SJ becomes Reserved our Model_Specific becomes illegal
    - Only the name of the parameter should determine if it is reserved
  - Ken: Putting it all in the Jitter BIRD makes sense
    - We should not guess what will happen in this BIRD
  - Walter: A model may have an Info putting jitter in the stimulus
    - Which branch does it go into?
  - Ken: Put it in Model_Specific if the model handles it
  - John: It's hard to see why we have branches
  - Kumar: It becomes very gray for jitter because it can go either way
  - Todd: If it's Info it's for the simulator
    - If Input it's for the model
    - If Output it's a result
  - Walter: There is confusion because this is in the .ami file, not the DLL
- Slide 5:
  - Walter: We couldn't use TX_Jitter and Rx_Clock_PDF
    - We thought no one was using it
    - If we keep them they should be clarified in the Jitter BIRD
- Slide 7:
  - Walter: This was already implemented by a model as an array
    - This change was to support that model, but we might not want to
    - It should be handled as Taps
  - Kumar: Agree
  - Arpad: We can contact the vendor
  - Ken: Is there any generic value in Table anyway?
  - Walter: A series of numbers could be passed by string
  - Ambrish: Or List
  - Walter: Then the DLL gets only one value
- Slide 8:
  - Walter: Agree
    - The DLL needs to know the number of taps
  - Ken: Is Step and Increment used anywhere?
  - Todd: Some lists just have too many values
- Slide 9:
  - Arpad: Are there any examples about MatLab data types?
  - Kumar: For example you only need matrix
    - A single number is a 1x1 matrix
    - Scientists need more types, engineers need less types
- Slide 10:
  - Walter: There will be issues with jitter, for example
    - For example jitter in the stimulus may be unclear

Bob: I didn't see the .ami section in the files sent by Walter
- Walter: That is in the reference document
  - I only said what I intended to do
- Bob: There is a problem with "In the context of"

Bob: IBISCHK is a good way to to test any syntax against 5.0

Next meeting: 30 Mar 2009 12:00pm PT

--------

IBIS Interconnect SPICE Wish List:

1) Simulator directives